---
title: "PR Tagging"
description: "How to trigger Open SWE runs by tagging it in PR comments and reviews"
---

<Warning>
  PR tagging functionality is **not available** on the demo application at [swe.langchain.com](https://swe.langchain.com). To use PR tagging, you must self-host Open SWE following the [development setup guide](/labs/swe/setup/development).
</Warning>

# PR Tagging Integration

Open SWE supports triggering automated runs directly from pull request interactions by tagging the agent in comments and reviews. This feature provides a seamless way to request code changes, ask questions, or resolve review feedback without leaving the GitHub interface.

## How PR Tagging Works

You can trigger Open SWE by mentioning `@open-swe` in any of the following contexts:

### PR Reviews
- **Leave a review** on a pull request and tag `@open-swe` in the review body
- Open SWE will process the entire review and resolve all comments within it
- Ideal for comprehensive feedback that requires multiple changes

### Review Comments
- **Tag `@open-swe`** in specific line-by-line review comments
- Open SWE will focus on resolving that particular comment
- Perfect for targeted fixes on specific code sections

### General PR Comments
- **Comment on the PR** and tag `@open-swe` to request general changes
- Open SWE will implement the requested modifications
- Best for broader changes or new feature requests

<Note>
  Each time you tag `@open-swe`, it creates a **new independent run**. Multiple tags in the same comment or across different comments will result in separate runs being executed.
</Note>

## Context and Security Considerations

<Warning>
  **Security Notice**: When you tag Open SWE in a PR, it will have access to **all comments, reviews, and review comments** on that pull request, along with any linked issues. Be aware of potential prompt injection attacks and avoid including sensitive information in PR discussions, or linked issues, when using this feature.
</Warning>

### What Context is Included

When Open SWE processes a PR tagging request, it automatically gathers:

- **All PR comments** (general discussion comments)
- **All reviews** (including their associated review comments)
- **All review comments** (line-by-line feedback)
- **Linked issues** referenced in the PR description (issue title and description)

### Linked Issues Detection

Open SWE automatically detects and includes linked issues using these keywords in the PR description:
- `fixes #123` or `fix #123`
- `closes #456` or `close #456`
- `resolves #789` or `resolve #789`

When these patterns are found, Open SWE will include the issue title and description as additional context for better understanding of the requirements.

## How Open SWE Responds

Open SWE can handle both **code changes** and **questions** depending on your request:

### Code Changes
When you request code modifications, Open SWE will:
1. **Create a new branch** pointing to the original PR branch
2. **Implement the requested changes** on this new branch
3. **Create a new pull request** with the changes
4. **Link the new PR** back to the original PR for easy review

This workflow ensures your original PR remains unchanged while allowing you to review the proposed modifications separately.

### Questions and Investigations
Open SWE can also respond to questions that don't require code changes:
- Ask about code functionality or architecture decisions
- Request explanations of existing implementations
- Get suggestions for alternative approaches

### Response Types by Comment Location

**Review Comments (line-by-line)**
- Open SWE replies **directly to the review comment**
- Response appears in the same conversation thread

**Review Messages (overall review)**
- Open SWE creates a **new comment** on the PR
- Quotes the original review and tags the reviewer
- Provides a comprehensive response to the review

**General PR Comments**
- Open SWE creates a **new comment** on the PR
- Quotes the original comment and tags the commenter
- Addresses the specific request or question

## Getting Started

To start using PR tagging:

1. **Ensure Open SWE is properly configured** for your repository (see self-hosting section below)
2. **Navigate to any pull request** in a repository where Open SWE is installed
3. **Leave a comment, review, or review comment** describing what you want
4. **Tag `@open-swe`** anywhere in your message
5. **Wait for Open SWE to respond** - it will reply immediately and begin processing

### Example Usage

```markdown
@open-swe can you refactor this function to use async/await instead of promises?
```

```markdown
This code looks good overall, but I think we need better error handling. 
@open-swe please add try-catch blocks and proper error logging.
```

```markdown
@open-swe what's the performance impact of this approach compared to the previous implementation?
```

## Self-Hosting Configuration

To use PR tagging with your self-hosted Open SWE instance, you'll need to configure a custom trigger username:

### Step 1: Create a GitHub User Account

Create a dedicated GitHub user account that will serve as your tagging trigger:
- Choose a username that's easy to remember (e.g., matching your GitHub App name)
- This account doesn't need any special permissions - it's just used for tagging

### Step 2: Update the Trigger Function

Modify the `mentionsGitHubUserForTrigger` function in `apps/open-swe/src/routes/github/utils.ts`:

```typescript
export function mentionsGitHubUserForTrigger(commentBody: string): boolean {
  return /@your-custom-username\b/.test(commentBody);
}
```

Replace `your-custom-username` with the GitHub username you created.

### Step 3: Set Environment Variable

Add the trigger username to your environment configuration in `apps/open-swe/.env`:

```bash
GITHUB_TRIGGER_USERNAME="your-custom-username"
```

This should match the username from Step 1 (without the @ symbol).

### Step 4: Update Allowed Users

Add the GitHub usernames who should be allowed to trigger runs to the `NEXT_PUBLIC_ALLOWED_USERS_LIST` environment variable in your agent's deployment environment (include in the production deployments for both the web app and agent to take advantage of the allowed users functionality).

```bash
NEXT_PUBLIC_ALLOWED_USERS_LIST='["your-github-username", "teammate-username"]'
```

When running locally, every user is an "allowed user". It's also recommended to set this environment variable in your web app's production environment variables so your users won't need to set their own API keys when invoking Open SWE via the web app.

<Tip>
  After making these configuration changes, restart your Open SWE instance to ensure the new settings take effect. You can then test the functionality by tagging your custom username in a PR comment.
</Tip>

## Best Practices

- **Be specific** in your requests to get better results
- **Use separate tags** for different types of changes to keep runs focused
- **Review generated PRs** before merging to ensure quality
- **Be mindful of context** - avoid sensitive information in PR discussions
- **Test with simple requests** first when setting up self-hosting

## Troubleshooting

If PR tagging isn't working:

1. **Check GitHub App permissions** - Ensure you have the required event subscriptions enabled
2. **Verify environment variables** - Confirm `GITHUB_TRIGGER_USERNAME` is set correctly
3. **Review allowed users** - Make sure your GitHub username is in the `ALLOWED_USERS` list
4. **Check webhook configuration** - Ensure webhooks are properly configured and receiving events
5. **Monitor logs** - Check the Open SWE logs for any error messages or debugging information

For additional help, refer to the [development setup guide](/labs/swe/setup/development) or check the GitHub repository for troubleshooting resources.
